Could we call this course_key? *_id in Django usually a foreign key, and I think it's unfortunate we've used course_id in so many places. I'd love to standardize on *_key for anything that's an OpaqueKey instance.

Yeah, I should have done that in the first place. Done: 88aef75

I have a sense that we'll eventually want to relax this in order to allow sites more flexibility on how they market their course runs, but I agree with adding the constraint for now and seeing how it plays out.

Turns out that I already had to relax it a bit, because it was breaking on CCX keys like ccx-v1:org+code+run+ccx@1 which don't end with +run. In fact, I realized CCX keys break a few different assumptions here - they also violate the constraint that (org, code, run) is unique per course run, because all CCX variants of a run have the same base course ID.

@bradenmacdonald I'm rusty on the CCX data model. Is every CCX considered a "course run" by the existing system? I know a CCX is a LearningContext, but does every CCX have a CourseOverview row?

Yes, every CCX instance is seen as a fully separate course run by most parts of the system (except Studio, which doesn't list them nor interact with them at all; CCX runs are created/edited/managed strictly through the LMS).

I just tested this now; here are the CourseOverviews of a CCX base course plus a CCX run created from it:

The logic below looks solid, but I'm curious what it handles that a this simpler logic wouldn't handle? ⬇️

if prev_org_code.lower() != new_org_code.lower():
    # If there are any runs, then changing the org code (other than capitalization) is forbidden.
    if CourseRun.objects.filter(catalog_course__org=instance).exists():
          raise ValidationError(...)

Is it so that if a CourseRun's course_key changes, then the org table can be updated to match? If so, do you mind dropping that in the comments?

I think the only such situation is this:

• An Organization "MITx" is renamed to "MIT" -> meanwhile all the associated course runs have keys like course-v1:MIT+foo+bar. Don't throw an error, because this is now "more correct".

This situation shouldn't really be possible if you are using these models correctly, but the "org.short_name matches course_key.org" rule is not actually enforced by the database, because we can't write constraints across table boundaries, and it involves parsing an opaque key. So it is possible if you are using the .update() manager API or raw/custom SQL, or anything else that bypasses the checks in course_run.clean()

The other advantage is that it states an exact, example course key in the ValidationError.

That said, I don't think the situation described above is likely to occur so I'd be fine with simplifying this to your suggestion.

Thinking about it more, I think I like what you have here. Generally speaking, it seems good to allow data changes towards correctness, rather than forbidding changes entirely. I can think of times where I've been burned by validation which whose intent was to keep my data correct, but it also effectively locked incorrect data into remaining incorrect. I'd say just drop a quick comment in to explain that, and keep it as-is.

Done: a27856f

Could you add more to this docstring? What is and isn't deleted by this function? And will that change when CourseRun becomes authoritative?

Sure: a27856f

Let me know if you have any thoughts on that, as I wasn't totally sure how it should behave or how we see it evolving.

@bradenmacdonald I'm rusty on the CCX data model. Is every CCX considered a "course run" by the existing system? I know a CCX is a LearningContext, but does every CCX have a CourseOverview row?

Doesn't openedx_content use title instead of display_name? Would it make sense to use title here and in CourseRun too?

If that's what we're moving toward, sure. I don't have any preference.

I'm wondering if we need a little guide of term preferences somewhere. vertical -> unit, sequential -> subsection, chapter -> section, course_id -> course_key, number -> course_code, display_name -> title, etc. There are a lot.

I should also mention that OLX uses display_name at every level, so we probably can't really change that completely. I do think title is better though.